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PROGRAMS IK LISP 
by John McCarthy 
1 * Introduction 

This merao depends only on the RLE QPR No. 53 discussion of 
LISP. Its object}. ve is to add to the system of that report a pro- 
gram feature . This takes the form of allowing functions to be de- 
fined by programs including sequences of Fortran-like statements, eg. 

y=cons[ff£subst[A;y;zJJ;(A,B)J 
Such a feature was included in the Informal version of LISP from 
which we hand-compiled Into SAP and is also available In the latest 
version of the apply operator. The version In the present apply 
operator is added merely as a convenience and does not have the 
mathematical elegance that we require. In the present memorandum, 
I will try to add a program feature to the system In a systematic 
way. It may be some time before this version is available In the 
^-^ programming system. 

Since ail computable functions can be expressed in LISP without 
the program feature, this feature can only be regarded as a con- 
venience. However, It is a convenience at which we cannot afford 
to sneer. 

This convenience has two aspects. 

1. It allows many programs tc be written more concisely and 
with a greater independence of the parts than djes the straight 
recursive function notation. 

2. it expresses the fact that many recursive functions are 
simpler uhan recursive functions are In general and can be compiled 
in a special way into programs that are more economical in time 
and data storage^than the most general form of recursive function. 
Specifically, this form of program Indicates that saving is un- 
necessary in certain cases and also that certain data are obsolete 
at certain points in the program anc that therefore it is possible 
to change old list structure rather than the prepare a new list 
structure with the changes . 

_ We shall discuss the two virtues of the program feature separately. 
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2 ' How Programs Shall Be Written 

In section 7 of the QPR article we describe a way of Inter- 
preting a program as a function. The state of the computer is 
represented by a vector ^ whose components are the variables of 
the program. Each section of the program is regarded as a 
function f which gives the change in ^ that takes place when 
this section executed, i.e. £ is changed to £'"<(>)• 

Consider a single replacement statement e.g. 

y=cons[ff£substfAjyizJ];(A,B)] 
The variables y and z are components of the quantity^, and we 
want to consider the function f which describes the transformation 
^♦^fCE) which occurs when the above replacement statement is 
executed. We can do this as follows: 

We regard £ as a list of the form 
( ( variable , value ) , ( variable , value ) ,e tc . ) 
and we define a function change as follows: 

change^ecivarival] « [nulljvec-* ^.^^^ jcaar&eel 
= var-*cons[list£var;vall ;cdr]vec]JiT-^ons£car{vecJ)clmnl^{edr£vec j; 

vsr;val]J]]| 

Then we can write 

f[^j - change^; Y; cons £ff {subs t JAjassocfY; £lassoc£Z;^J|J 

(A,B)]] 

The effect of executing in order the replacement statements 

represented by the functions f,g and h is described hy the function 
x LfeT? h [«pW)l]- The reversal of order is caused by the fact that 
the composition of functions is described by listing the functions 
in an order opposite to their order of performance. 

We can now give an S-function which gives the function 
corresponding to a sequence of statements. A statement is represented 
by a pair consisting of the variable to be changed and the expres- 
sion which defines its new value. Thus the statement 

y » cons[ff jsubst£A;yjzJ}i(A,B)7 
is represented by the pair 

(Y, (CONS, (FF, (SUBST, (QUGTE,A) ,E) ), (QUOTE, (A,B) )) ) 
and the program is represented by the list of its statements in 
the order in which they are to be executed. 

We now define the function 

program fir ;"£*] = rnull£v]--^|#T-H»pre^amro^^rJjchanger^ 

n ?,' ft r« fprl *. < ■ v ,-» 1 \c H <te v frrT ; V 11 | ! 
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Thls form of program f eature has the advantage that the vector ^, 
can be different on different uses of a program and different 
fes with the same variables can have different values assigned 
to the variables. In particular, if a program is started with 
NIL for"fe all assignments start from scratch. 

The simple form of program feature given above can profitably 
be elaborated. The following features may be added. 

1, Transfers of control . We can do this by making IL 
(for instruction location) a special variable. The program 
function then becomes 

program2fji g=£null[7Q-^«caar£Fj*IL--»program2£eval£cadar jjj; 
^] ; t ];T~*program2 £cdr [irl ;eval JcadarjVj j'isT'n 

This allows transfer of control to any part of the program 
that can be computed. However, without a system of labelling 
statements it is difficult to describe these computations. One 
way of labelling statements is to describe the individual program 
step by a triplet rather than by a pair. This would require a 
slight modification of the above function. 

Another method is to keep a separate list of pairs whose 
elements consist of labels and the locations of the corresponding 
statements. 

2. Simultaneous change of several variables . As an example 
of this feature, suppose we wish tc exchange the values of the 
variables X and Y. The program ((X,Y),(Y,X)) will not do it 
because X Is changed before Y is computed. If we write 
(U,Y),(X,Y),(Y,V)) we get a program for this, but it is objection- 
able to have to introduce the auxiliary variable U. 

Let us consider a new form of program each of whose statements 
generates a list of pairs each element of which consists of a 
variable and a value. Our rule is to change the vector ^accord- 
ing to the list of pairs produced. We have 

program3nrj|l*£hull£irl-^ijT-^rogram3£cdr£*w7 ;change2J£ jeval 

The function ohapge2 takes the list of pairs produced by the 
program step and makes the indicated changes in the vector^. 

I shall write changes assuming that there is an ordering of 
atomic symbols denoted by < and that ttue vector |* and the vectors 
produced by the program steps have their first elements of the pairs 
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ordered ascendingly. 

We have 

changed [Vec ; lis t3*|rmll[vecj— Jlist ; " 
mil 1 [l 1 3 tl~^ve c $ caar £ve c J =caar jfl is fcj — "> 
consfcarfllst) jclmi^epdr£vecl;cdrjlistl|} 
eaar£vecj<caar flis tj~* cons 
jTearrvec] $ change ^ 
c one j^ar£l 1st J; change £vec jcdrflistjj JJ 

It is not difficult to combine the previous incorporation 
of transfer instructions with the present inclusion of simul- 
taneous changes. 
3 • Efficiency o f Programs 

In developing LISP our first goal is to describe a language 
fcthlch Is as powerful as possible from the point of view of the 
programmer. More precisely, we wish to be able to describe the 
transformation between the input of a program and the desired 
output as directly as possible. How is it possible to say that 
one programming language is more powerful than another when It 
is known that a programming language containing only the 704 
Instructions SUB, STO, and TMI is adequate for describing any 
computable function? We must be able to refine the concept of 
power of a language for describing computations beyond merely 
taking into account the set of processes that can be described 
in order to usefully compare programming languages. 

One approach to refining the concept has to do with 
auxiliary quantities occurring in the calculation; I shall give 
two examples. First, since IISP operates on the 70*, the 704 
translation of a LISP program describes the same process. How- 
ever, the 704 program makes explicit reference to auxiliary 
quantities and processes such as the free storage list, the 
public push-down list, the contents, of index registers, and many 
other registers and subroutines that are hidden from the LISP 
programmer . The superiority of LISP to machine language from 
the point of the view of the programmer is that he need not 
introduce these auxiliary entities in order to describe his 
process. As a second example consider matrix multiplication. 
The machine operations which occur in carrying it out include 
n multiplications and the (n-l)n^ additions which go into the 
evaluation of the elements of the product matrix. An actual 
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arithmetic operations, for example additions to the subscripts 
of matrix elements, but the purpose of these is merely to insure 
that the correct matrix elements are multiplied and added and 
the results put in the right place. We shall consider one pro- 
gramming system more powerful than another if functions which 
can be described directlv in the pne require the description of 
auxiliary computation in the other. 

Of course, when the computations are to be performed on 
an actual computer, the auxiliary processes still have to be 
performed whether the programmer has to describe them or whether 
they are automatically generated by the translation of the pro- 
gramming language into machine instructions. 

It was shown in the QPR extract that a program described 
by a flow chart could have this description readily translated 
into a description using recursive functions. The converse is 
not true. A recursive function such as subs t can be described 
by a computer program only if the use of the public push-down 
list is explicitly incorporated in the program. In fact, flow 
charts translate into recursive functions with special properties 
Recall that a portion of a flow chart as shown in the figure 
give 8 rise to a recursive function 
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The computation of any of thed)'s is referred after a decision 
is made (by the p's) and a preliminary calculation is made (by an f) 
fco the evaluation of a single ^i. Contrast this with the fact that 
the evaluation of subst£sc;y;£j generally involves the calculation 
of both subs tfx;y; car [zj] and subst£x;yjedr[s5jj. 
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This Implies that 

1 . The program for a function <p does not use the programs 
for the other d> r s as subroutines but transfers control to them 
irrevocably. (In 704 language, a TEA is used rather than a TSX) . 
Therefore, no push-down list is required to save temporary results. 

2. The vector t can be regarded as a single-valued quantity 
which changes during the execution of the program. In the more 
general kind of recursion functions of the form f^igfe}] 1 ^ occur 
which means that the original value of ^ must be preserved while 
gfife] is computed. The LISP program feature described in the 
previous section allow programs to be expressed that require this 
kind of saving. 

We may ask how the machine language program corresponding 
to a LISP program looks. The answer is that the vector ^ in 
the machine language program contains many more components than 
the original LISP program including components describing the 
push-down situation and the recursion situation. 

The generality of the recursive function way of describing , 
computation processes has certain disadvantages which have to 
be overcome. If we describe a computation process as a recursive 
function which is of the special kind that can be represented by 
a flow chart and our compilation process (either by a compiler 
or by hand) does not take this into account an inefficient program 
will result. The following inefficiencies can occur. 

1. In general when a block of computation is performed a 
complete new vector^ must be computed and the old one saved. 
(If the old one is never used it will be abandoned and later 
picked up by the reclamation program). In general, some components 
will be recomputed and the others will be copied along the top 
line. In the special case, however, it would suffice to compute 
new values for some of the components and store the result in 

the vector. Such a process cannot be accomplished using car , cdr 
and cjrns since the functions never change existing list structure. 

2. When control is transfered without the possibility of 
return the original state of the computation need not be saved. 
The "transfer" Instruction in the program feature of the previous 
section has this efficiency. 
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3. If only one vector £ is \p«^$!|?*il 
possible. In the present system in write* 
a variable it is necessary to search ttte 
but one such vector and the program is 
can be written so as to refer directly ' 
search Is required. 

We hope to explore the possibility 
compiler ways of determining when a 
can be used with a saving of tiffl*: 
is to provide a way for the 
latlon has special properties 
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